Skip to main content

Tell Cases apart

Git Config: core.ignorecase false ⚙️​

This document outlines the functionality and implications of the Git configuration setting core.ignorecase when set to false.

What is core.ignorecase?​

The core.ignorecase setting in Git determines how Git handles case sensitivity for file names.

  • true (default on case-insensitive file systems like Windows and macOS): Git will treat filenames that differ only in case as the same file. For example, File.txt and file.txt would be considered identical.
  • false (default on case-sensitive file systems like Linux): Git will treat filenames that differ in case as distinct files. For example, File.txt and file.txt would be considered two separate files.

Setting core.ignorecase false​

You can set core.ignorecase to false using the following Git command:

git config core.ignorecase false

This command can be applied at different levels:

  • --local: Applies only to the current repository (default if no option is specified within a repository).
  • --global: Applies to all repositories for the current user.
  • --system: Applies to all users on the system (requires administrator privileges).

Important Note: It's generally not recommended to set core.ignorecase to false on a case-insensitive file system (like Windows or default macOS) if the repository is already tracking files in a way that relies on case-insensitivity. Doing so can lead to unexpected behavior and issues.

Why Use core.ignorecase false?​

Setting core.ignorecase false is typically done to enforce strict case sensitivity in a Git repository. This can be useful in scenarios such as:

  • Cross-platform Development: When developers are working on different operating systems (e.g., some on Linux, some on Windows), ensuring case sensitivity can prevent issues where file casing differences cause problems on case-sensitive systems.
  • Preventing Casing Conflicts: It helps avoid accidental creation of files that differ only in case, which can lead to confusion and bugs, especially when deploying to or collaborating with systems that are case-sensitive.
  • Maintaining Consistency: For projects that require strict adherence to naming conventions, including case.

Potential Issues and Considerations ⚠️​

Setting core.ignorecase false on a file system that is inherently case-insensitive (like default Windows or macOS) can lead to several problems:

  • Git Confusion: Git might report files as untracked, modified, or deleted when the only difference is their casing, even though the file system sees them as the same file. This can make staging and committing changes difficult and error-prone.
  • Collaboration Problems: If some collaborators are on case-insensitive systems and others are on case-sensitive systems, and core.ignorecase is set to false inconsistently or on a case-insensitive filesystem, it can lead to merge conflicts and broken builds. For instance, one user might commit MyFile.java and another myfile.java. On a case-sensitive system, these are two different files. On a case-insensitive system, the second commit might overwrite the first, or Git might get confused.
  • File System Limitations: Git cannot fully overcome the limitations of the underlying file system. If the OS treats File.txt and file.txt as the same file, Git (even with core.ignorecase false) might struggle to accurately track them as distinct entities if both are present or if casing is changed in a way the OS doesn't register as a new file.

Best Practice: The core.ignorecase setting should ideally match the case sensitivity of the primary development and deployment file systems. If you are on Windows or macOS and need to manage files with different casing that the OS treats as the same, it's often better to rename files consistently and avoid relying on core.ignorecase false to manage this, as it can lead to a confusing state.

When is it "Safer" to Use core.ignorecase false?​

  • When your entire team and your deployment environment use case-sensitive file systems (e.g., Linux).
  • When starting a new project on a case-sensitive file system and you want to enforce this from the beginning.

If you are on a case-insensitive file system and need to fix existing casing issues in your repository (e.g., you have Readme.md and readme.md tracked, which is problematic), a common approach is:

  1. Rename the file to a completely new temporary name: git mv Readme.md temp-readme.md
  2. Commit the rename: git commit -m "Rename Readme.md to temporary name"
  3. Rename it back to the desired casing: git mv temp-readme.md README.md
  4. Commit the final rename: git commit -m "Correct casing for README.md"

This process helps Git correctly track the change in casing, even on case-insensitive file systems.

In summary, while git config core.ignorecase false provides control over how Git perceives file name casing, it should be used with a clear understanding of your operating system's file system behavior and the potential impact on your workflow and collaboration, especially in mixed-OS environments.